home *** CD-ROM | disk | FTP | other *** search
/ PC World Komputer 2010 April / PCWorld0410.iso / hity wydania / Ubuntu 9.10 PL / karmelkowy-koliberek-desktop-9.10-i386-PL.iso / casper / filesystem.squashfs / usr / share / snmp / mibs / INET-ADDRESS-MIB.txt < prev    next >
Text File  |  2009-10-02  |  17KB  |  403 lines
  1. INET-ADDRESS-MIB DEFINITIONS ::= BEGIN
  2.  
  3. IMPORTS
  4.     MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI
  5.     TEXTUAL-CONVENTION                 FROM SNMPv2-TC;
  6.  
  7. inetAddressMIB MODULE-IDENTITY
  8.     LAST-UPDATED "200502040000Z"
  9.     ORGANIZATION
  10.         "IETF Operations and Management Area"
  11.     CONTACT-INFO
  12.         "Juergen Schoenwaelder (Editor)
  13.          International University Bremen
  14.          P.O. Box 750 561
  15.          28725 Bremen, Germany
  16.  
  17.          Phone: +49 421 200-3587
  18.          EMail: j.schoenwaelder@iu-bremen.de
  19.  
  20.          Send comments to <ietfmibs@ops.ietf.org>."
  21.     DESCRIPTION
  22.         "This MIB module defines textual conventions for
  23.          representing Internet addresses.  An Internet
  24.          address can be an IPv4 address, an IPv6 address,
  25.          or a DNS domain name.  This module also defines
  26.          textual conventions for Internet port numbers,
  27.          autonomous system numbers, and the length of an
  28.          Internet address prefix.
  29.  
  30.          Copyright (C) The Internet Society (2005).  This version
  31.          of this MIB module is part of RFC 4001, see the RFC
  32.          itself for full legal notices."
  33.     REVISION     "200502040000Z"
  34.     DESCRIPTION
  35.         "Third version, published as RFC 4001.  This revision
  36.          introduces the InetZoneIndex, InetScopeType, and
  37.          InetVersion textual conventions."
  38.     REVISION     "200205090000Z"
  39.     DESCRIPTION
  40.         "Second version, published as RFC 3291.  This
  41.          revision contains several clarifications and
  42.          introduces several new textual conventions:
  43.          InetAddressPrefixLength, InetPortNumber,
  44.          InetAutonomousSystemNumber, InetAddressIPv4z,
  45.          and InetAddressIPv6z."
  46.     REVISION     "200006080000Z"
  47.     DESCRIPTION
  48.         "Initial version, published as RFC 2851."
  49.     ::= { mib-2 76 }
  50.  
  51. InetAddressType ::= TEXTUAL-CONVENTION
  52.     STATUS      current
  53.     DESCRIPTION
  54.         "A value that represents a type of Internet address.
  55.  
  56.          unknown(0)  An unknown address type.  This value MUST
  57.                      be used if the value of the corresponding
  58.                      InetAddress object is a zero-length string.
  59.                      It may also be used to indicate an IP address
  60.                      that is not in one of the formats defined
  61.                      below.
  62.  
  63.          ipv4(1)     An IPv4 address as defined by the
  64.                      InetAddressIPv4 textual convention.
  65.  
  66.          ipv6(2)     An IPv6 address as defined by the
  67.                      InetAddressIPv6 textual convention.
  68.  
  69.          ipv4z(3)    A non-global IPv4 address including a zone
  70.                      index as defined by the InetAddressIPv4z
  71.                      textual convention.
  72.  
  73.          ipv6z(4)    A non-global IPv6 address including a zone
  74.                      index as defined by the InetAddressIPv6z
  75.                      textual convention.
  76.  
  77.          dns(16)     A DNS domain name as defined by the
  78.                      InetAddressDNS textual convention.
  79.  
  80.          Each definition of a concrete InetAddressType value must be
  81.          accompanied by a definition of a textual convention for use
  82.          with that InetAddressType.
  83.  
  84.          To support future extensions, the InetAddressType textual
  85.          convention SHOULD NOT be sub-typed in object type definitions.
  86.          It MAY be sub-typed in compliance statements in order to
  87.          require only a subset of these address types for a compliant
  88.          implementation.
  89.  
  90.          Implementations must ensure that InetAddressType objects
  91.          and any dependent objects (e.g., InetAddress objects) are
  92.          consistent.  An inconsistentValue error must be generated
  93.          if an attempt to change an InetAddressType object would,
  94.          for example, lead to an undefined InetAddress value.  In
  95.  
  96.          particular, InetAddressType/InetAddress pairs must be
  97.          changed together if the address type changes (e.g., from
  98.          ipv6(2) to ipv4(1))."
  99.     SYNTAX       INTEGER {
  100.                      unknown(0),
  101.                      ipv4(1),
  102.                      ipv6(2),
  103.                      ipv4z(3),
  104.                      ipv6z(4),
  105.                      dns(16)
  106.                  }
  107.  
  108. InetAddress ::= TEXTUAL-CONVENTION
  109.     STATUS      current
  110.     DESCRIPTION
  111.         "Denotes a generic Internet address.
  112.  
  113.          An InetAddress value is always interpreted within the context
  114.          of an InetAddressType value.  Every usage of the InetAddress
  115.          textual convention is required to specify the InetAddressType
  116.          object that provides the context.  It is suggested that the
  117.          InetAddressType object be logically registered before the
  118.          object(s) that use the InetAddress textual convention, if
  119.          they appear in the same logical row.
  120.  
  121.          The value of an InetAddress object must always be
  122.          consistent with the value of the associated InetAddressType
  123.          object.  Attempts to set an InetAddress object to a value
  124.          inconsistent with the associated InetAddressType
  125.          must fail with an inconsistentValue error.
  126.  
  127.          When this textual convention is used as the syntax of an
  128.          index object, there may be issues with the limit of 128
  129.          sub-identifiers specified in SMIv2, STD 58.  In this case,
  130.          the object definition MUST include a 'SIZE' clause to
  131.          limit the number of potential instance sub-identifiers;
  132.          otherwise the applicable constraints MUST be stated in
  133.          the appropriate conceptual row DESCRIPTION clauses, or
  134.          in the surrounding documentation if there is no single
  135.          DESCRIPTION clause that is appropriate."
  136.     SYNTAX       OCTET STRING (SIZE (0..255))
  137.  
  138. InetAddressIPv4 ::= TEXTUAL-CONVENTION
  139.     DISPLAY-HINT "1d.1d.1d.1d"
  140.     STATUS       current
  141.     DESCRIPTION
  142.         "Represents an IPv4 network address:
  143.  
  144.            Octets   Contents         Encoding
  145.             1-4     IPv4 address     network-byte order
  146.  
  147.          The corresponding InetAddressType value is ipv4(1).
  148.  
  149.          This textual convention SHOULD NOT be used directly in object
  150.          definitions, as it restricts addresses to a specific format.
  151.          However, if it is used, it MAY be used either on its own or in
  152.          conjunction with InetAddressType, as a pair."
  153.     SYNTAX       OCTET STRING (SIZE (4))
  154.  
  155. InetAddressIPv6 ::= TEXTUAL-CONVENTION
  156.     DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x"
  157.     STATUS       current
  158.     DESCRIPTION
  159.         "Represents an IPv6 network address:
  160.  
  161.            Octets   Contents         Encoding
  162.             1-16    IPv6 address     network-byte order
  163.  
  164.          The corresponding InetAddressType value is ipv6(2).
  165.  
  166.          This textual convention SHOULD NOT be used directly in object
  167.          definitions, as it restricts addresses to a specific format.
  168.          However, if it is used, it MAY be used either on its own or in
  169.          conjunction with InetAddressType, as a pair."
  170.     SYNTAX       OCTET STRING (SIZE (16))
  171.  
  172. InetAddressIPv4z ::= TEXTUAL-CONVENTION
  173.     DISPLAY-HINT "1d.1d.1d.1d%4d"
  174.     STATUS       current
  175.     DESCRIPTION
  176.         "Represents a non-global IPv4 network address, together
  177.          with its zone index:
  178.  
  179.            Octets   Contents         Encoding
  180.             1-4     IPv4 address     network-byte order
  181.             5-8     zone index       network-byte order
  182.  
  183.          The corresponding InetAddressType value is ipv4z(3).
  184.  
  185.          The zone index (bytes 5-8) is used to disambiguate identical
  186.          address values on nodes that have interfaces attached to
  187.          different zones of the same scope.  The zone index may contain
  188.          the special value 0, which refers to the default zone for each
  189.          scope.
  190.  
  191.          This textual convention SHOULD NOT be used directly in object
  192.  
  193.          definitions, as it restricts addresses to a specific format.
  194.          However, if it is used, it MAY be used either on its own or in
  195.          conjunction with InetAddressType, as a pair."
  196.     SYNTAX       OCTET STRING (SIZE (8))
  197.  
  198. InetAddressIPv6z ::= TEXTUAL-CONVENTION
  199.     DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
  200.     STATUS       current
  201.     DESCRIPTION
  202.         "Represents a non-global IPv6 network address, together
  203.          with its zone index:
  204.  
  205.            Octets   Contents         Encoding
  206.             1-16    IPv6 address     network-byte order
  207.            17-20    zone index       network-byte order
  208.  
  209.          The corresponding InetAddressType value is ipv6z(4).
  210.  
  211.          The zone index (bytes 17-20) is used to disambiguate
  212.          identical address values on nodes that have interfaces
  213.          attached to different zones of the same scope.  The zone index
  214.          may contain the special value 0, which refers to the default
  215.          zone for each scope.
  216.  
  217.          This textual convention SHOULD NOT be used directly in object
  218.          definitions, as it restricts addresses to a specific format.
  219.          However, if it is used, it MAY be used either on its own or in
  220.          conjunction with InetAddressType, as a pair."
  221.     SYNTAX       OCTET STRING (SIZE (20))
  222.  
  223. InetAddressDNS ::= TEXTUAL-CONVENTION
  224.     DISPLAY-HINT "255a"
  225.     STATUS       current
  226.     DESCRIPTION
  227.         "Represents a DNS domain name.  The name SHOULD be fully
  228.          qualified whenever possible.
  229.  
  230.          The corresponding InetAddressType is dns(16).
  231.  
  232.          The DESCRIPTION clause of InetAddress objects that may have
  233.          InetAddressDNS values MUST fully describe how (and when)
  234.          these names are to be resolved to IP addresses.
  235.  
  236.          The resolution of an InetAddressDNS value may require to
  237.          query multiple DNS records (e.g., A for IPv4 and AAAA for
  238.          IPv6).  The order of the resolution process and which DNS
  239.          record takes precedence depends on the configuration of the
  240.          resolver.
  241.  
  242.          This textual convention SHOULD NOT be used directly in object
  243.          definitions, as it restricts addresses to a specific format.
  244.          However, if it is used, it MAY be used either on its own or in
  245.          conjunction with InetAddressType, as a pair."
  246.     SYNTAX       OCTET STRING (SIZE (1..255))
  247.  
  248. InetAddressPrefixLength ::= TEXTUAL-CONVENTION
  249.     DISPLAY-HINT "d"
  250.     STATUS       current
  251.     DESCRIPTION
  252.         "Denotes the length of a generic Internet network address
  253.          prefix.  A value of n corresponds to an IP address mask
  254.          that has n contiguous 1-bits from the most significant
  255.          bit (MSB), with all other bits set to 0.
  256.  
  257.          An InetAddressPrefixLength value is always interpreted within
  258.          the context of an InetAddressType value.  Every usage of the
  259.          InetAddressPrefixLength textual convention is required to
  260.          specify the InetAddressType object that provides the
  261.          context.  It is suggested that the InetAddressType object be
  262.          logically registered before the object(s) that use the
  263.          InetAddressPrefixLength textual convention, if they appear
  264.          in the same logical row.
  265.  
  266.          InetAddressPrefixLength values larger than
  267.          the maximum length of an IP address for a specific
  268.          InetAddressType are treated as the maximum significant
  269.          value applicable for the InetAddressType.  The maximum
  270.          significant value is 32 for the InetAddressType
  271.          'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType
  272.          'ipv6(2)' and 'ipv6z(4)'.  The maximum significant value
  273.          for the InetAddressType 'dns(16)' is 0.
  274.  
  275.          The value zero is object-specific and must be defined as
  276.          part of the description of any object that uses this
  277.          syntax.  Examples of the usage of zero might include
  278.          situations where the Internet network address prefix
  279.          is unknown or does not apply.
  280.  
  281.          The upper bound of the prefix length has been chosen to
  282.          be consistent with the maximum size of an InetAddress."
  283.     SYNTAX       Unsigned32 (0..2040)
  284.  
  285. InetPortNumber ::= TEXTUAL-CONVENTION
  286.     DISPLAY-HINT "d"
  287.     STATUS       current
  288.     DESCRIPTION
  289.         "Represents a 16 bit port number of an Internet transport
  290.  
  291.          layer protocol.  Port numbers are assigned by IANA.  A
  292.          current list of all assignments is available from
  293.          <http://www.iana.org/>.
  294.  
  295.          The value zero is object-specific and must be defined as
  296.          part of the description of any object that uses this
  297.          syntax.  Examples of the usage of zero might include
  298.          situations where a port number is unknown, or when the
  299.          value zero is used as a wildcard in a filter."
  300.     REFERENCE   "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960"
  301.     SYNTAX       Unsigned32 (0..65535)
  302.  
  303. InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION
  304.     DISPLAY-HINT "d"
  305.     STATUS       current
  306.     DESCRIPTION
  307.         "Represents an autonomous system number that identifies an
  308.          Autonomous System (AS).  An AS is a set of routers under a
  309.          single technical administration, using an interior gateway
  310.          protocol and common metrics to route packets within the AS,
  311.          and using an exterior gateway protocol to route packets to
  312.          other ASes'.  IANA maintains the AS number space and has
  313.          delegated large parts to the regional registries.
  314.  
  315.          Autonomous system numbers are currently limited to 16 bits
  316.          (0..65535).  There is, however, work in progress to enlarge the
  317.          autonomous system number space to 32 bits.  Therefore, this
  318.          textual convention uses an Unsigned32 value without a
  319.          range restriction in order to support a larger autonomous
  320.          system number space."
  321.     REFERENCE   "RFC 1771, RFC 1930"
  322.     SYNTAX       Unsigned32
  323.  
  324. InetScopeType ::= TEXTUAL-CONVENTION
  325.     STATUS       current
  326.     DESCRIPTION
  327.         "Represents a scope type.  This textual convention can be used
  328.          in cases where a MIB has to represent different scope types
  329.          and there is no context information, such as an InetAddress
  330.          object, that implicitly defines the scope type.
  331.  
  332.          Note that not all possible values have been assigned yet, but
  333.          they may be assigned in future revisions of this specification.
  334.          Applications should therefore be able to deal with values
  335.          not yet assigned."
  336.     REFERENCE   "RFC 3513"
  337.     SYNTAX       INTEGER {
  338.                      -- reserved(0),
  339.                      interfaceLocal(1),
  340.                      linkLocal(2),
  341.                      subnetLocal(3),
  342.                      adminLocal(4),
  343.                      siteLocal(5), -- site-local unicast addresses
  344.                                    -- have been deprecated by RFC 3879
  345.                      -- unassigned(6),
  346.                      -- unassigned(7),
  347.                      organizationLocal(8),
  348.                      -- unassigned(9),
  349.                      -- unassigned(10),
  350.                      -- unassigned(11),
  351.                      -- unassigned(12),
  352.                      -- unassigned(13),
  353.                      global(14)
  354.                      -- reserved(15)
  355.                  }
  356.  
  357. InetZoneIndex ::= TEXTUAL-CONVENTION
  358.     DISPLAY-HINT "d"
  359.     STATUS       current
  360.     DESCRIPTION
  361.         "A zone index identifies an instance of a zone of a
  362.          specific scope.
  363.  
  364.          The zone index MUST disambiguate identical address
  365.          values.  For link-local addresses, the zone index will
  366.          typically be the interface index (ifIndex as defined in the
  367.          IF-MIB) of the interface on which the address is configured.
  368.  
  369.          The zone index may contain the special value 0, which refers
  370.          to the default zone.  The default zone may be used in cases
  371.          where the valid zone index is not known (e.g., when a
  372.          management application has to write a link-local IPv6
  373.          address without knowing the interface index value).  The
  374.          default zone SHOULD NOT be used as an easy way out in
  375.          cases where the zone index for a non-global IPv6 address
  376.          is known."
  377.     REFERENCE   "RFC4007"
  378.     SYNTAX       Unsigned32
  379.  
  380. InetVersion ::= TEXTUAL-CONVENTION
  381.     STATUS  current
  382.     DESCRIPTION
  383.         "A value representing a version of the IP protocol.
  384.  
  385.          unknown(0)  An unknown or unspecified version of the IP
  386.                      protocol.
  387.  
  388.          ipv4(1)     The IPv4 protocol as defined in RFC 791 (STD 5).
  389.  
  390.          ipv6(2)     The IPv6 protocol as defined in RFC 2460.
  391.  
  392.          Note that this textual convention SHOULD NOT be used to
  393.          distinguish different address types associated with IP
  394.          protocols.  The InetAddressType has been designed for this
  395.          purpose."
  396.     REFERENCE   "RFC 791, RFC 2460"
  397.     SYNTAX       INTEGER {
  398.                      unknown(0),
  399.                      ipv4(1),
  400.                      ipv6(2)
  401.                  }
  402. END
  403.